Nabble - Maven Developers

Developing Maven 2.1

2008-07-05T10:56:10Z

I have put together a visual of the system, some information on using
m2eclipse to debug the entire platform, and the use of Hudson for
testing the resulting system.

http://docs.codehaus.org/display/MAVEN/Developing+Maven+2.1

The guide included there (put together by Igor) should allow anyone to
debug the entire toolchain (Plexus, XBR, Classworlds, Maven ...) from
within Eclipse which will make developing and debugging easier. You
can actually execute Maven plugins from within the workspace (i.e you
don't have to install it) using m2e.

I will start collapsing all the cruft that's built up around 2.1 and
flesh out that landing page as I start automating more in Hudson, and
building out the Hudson nodes that will support other standard
platforms.

If you want to surf around Hudson you can look at it here:

http://ci.sonatype.org/

There are groups there for Maven 2.1, Plexus, Maven IDE (really
embedder consumers), and I will also limit the plugins to the default
lifecycles of the commonly used packagings like JAR, and WAR. John has
also started creating automated ways to release to stage, and
subsequent promotion upon success. So for any component in the tool
chain there will be a way to do a consistent release from a canonical
machine.

I am also working with the Apache Infrastructure team to integrate the
Contegix folks who are the ones who currently host all the hardware
we're using. Maven's central repository, our Hudson instance, and our
Nexus instance. So, in short order, the Contegix hardware will be
official Apache hardware.

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

A language that doesn’t affect the way you think about programming is
not worth knowing.

-— Alan Perlis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Testing Maven 2.x Embedding

2008-07-05T09:00:59Z

Milos, can you help me copy the Mevenide job from deadlock?

I can see from the output here what the CLI looks like but there are a
couple options I don't really understand:

http://deadlock.netbeans.org/hudson/job/mevenide/423/console

On 22-Jun-08, at 3:13 PM, Milos Kleint wrote:

> On Sun, Jun 22, 2008 at 8:44 PM, Jason van Zyl <jason@...>
> wrote:
>>
>> On 22-Jun-08, at 11:37 AM, Milos Kleint wrote:
>>
>>> On Sun, Jun 22, 2008 at 8:18 PM, Jason van Zyl <jason@...>
>>> wrote:
>>>>
>>>> Milos,
>>>>
>>>> Do you need anything other then the standard embedder that's
>>>> produced by
>>>> the
>>>> build to run your automated tests?
>>>
>>> I don't really have any automated tests. The wide variety of
>>> problems
>>> I've encountered so far sort of convince me that I would just spend
>>> time on them without much effect. I rely on the maven's own
>>> integration tests instead. That's what people working on maven care
>>> about anyway primarily.
>>>
>>> I'm using the -Pnetbeans profile for building the embedder bits,
>>> as I
>>> think shading is still necessary in embedded env.
>>>
>>>
>>>>
>>>> I'm trying to hook the standard output to m2e, and I wanted to
>>>> try and do
>>>> the same with the Netbeans integration so that we can get more
>>>> feedback
>>>> on
>>>> changes in the trunk as they happen over the course of the
>>>> releases that
>>>> will start shortly.
>>>
>>> what does "hook the standard output to m2e" mean?
>>>
>>
>> We have quite a few automated tests, so to feed the embedder that
>> produced
>> and wire it into m2e's automated tests as a smoke test.
>>
>>>
>>>>
>>>> I know you have your builds in the Sun instance of Hudson but can
>>>> you
>>>> help
>>>> me setup a Netbeans build in Hudson so we can run whatever
>>>> automated
>>>> tests
>>>> you have so that we can catch problems with embedding faster?
>>>
>>> it's basically a "mvn install nbm:nbm nbm:cluster" but mvn install
>>> shall be enough as well. only a few unit tests there (as I don't
>>> believe in UI testing :) - or rather I don't believe that the value
>>> added to time spent ratio is good in the long run)
>>>
>>> My testing usually involves opening and working with multiple
>>> complex
>>> projects like mevenide, glassfish or hudson to see if things keep
>>> working..
>>>
>>> If writing tests is reasonably easy at maven, I could write some
>>> here
>>> eventually, but generally I'm turned down by any complex test setup.
>>> That's where the tests belong anyway IMHO.
>>>
>>
>> We really just have tests for the actions in m2e. Testing the UI is
>> a test
>> plan and human, no way around that but where I can determine
>> something done
>> in the embedder causes easily detectable problems I'd like to know
>> about
>> them sooner rather then later.
>>
>> Given m2e and netbeans are the primary consumers at this point it
>> would be
>> good to at least keep you guys in Hudson and make sure everything is
>> working. At least at a high level.
>>
>
> Fine with me. However please note that without the manual UI testing
> you probably only figure netbeans integration doesn't compile (which
> actually can be useful as I do override implementations of a few core
> components.)
>
> From top of my head the 3.1.1 release of mevenide had a problem with
> RELEASE version resolution, I've fixed it later, updated to latest
> version just to find out that now the 3.1.3 version has a problem with
> long dependency versions (fixed now in trunk but still I need to
> perform a re-release to push it to users)
> These should have been cought by the integration or unit tests in
> maven itself. I usually only figure when people report the problem to
> me or encounter the issue myself.
>
> Milos
>
>>> greetings.
>>>
>>> Milos
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> jason at sonatype dot com
>>>> ----------------------------------------------------------
>>>>
>>>> A party which is not afraid of letting culture,
>>>> business, and welfare go to ruin completely can
>>>> be omnipotent for a while.
>>>>
>>>> -- Jakob Burckhardt
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> In short, man creates for himself a new religion of a rational
>> and technical order to justify his work and to be justified in it.
>>
>> -- Jacques Ellul, The Technological Society
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

To do two things at once is to do neither.

-—Publilius Syrus, Roman slave, first century B.C.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

2008-07-05T08:15:56Z

On 05/07/2008, at 1:44 AM, Jason van Zyl wrote:

> Are you dropping new files into the local repository or integrating
> this as part of the metadata? Do these files only work locally?

The current impl, from what I've seen of it, drops properties files
into the local repository only, and doesn't alter the metadata files
that should match the remote repository. My question to John was
whether he was saying that was the best place to put it, or to simply
write out a POM that matches the internally used stub model as we used
to do.

>
>
> Also in the case of 2.1 we should also consider just not allowing
> the state where there is no POM. Consider the artifact not complete
> without a POM.

Since Igor, John and Brian felt this was serious enough to delay a
release because it was slow, I don't think they'd be particularly
happy with it failing instead :)

In principle I agree, but I think we need to do more to push this to
happen such that it is unlikely to affect a large number of builds - I
don't think that'd be the case today. More ominous deprecation
warnings perhaps. The problem here may be that it is still not easy
enough for non-M2 projects (both Maven 1 and Ant/other) to make their
artifacts available to Maven repositories properly (as we've seen in
some blogs very recently). But that's a separate discussion.

Cheers,
Brett

>
>
> On 4-Jul-08, at 11:29 AM, Brett Porter wrote:
>
>>
>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>
>>> Not to distract from the higher-level discussion, but I'd like to
>>> get into the nuts and bolts of MARTIFACT-25 a bit...in case
>>> someone beats me to it.
>>>
>>> We introduced a properties file that tracks resolution attempts
>>> for artifacts that weren't found on the remote repository, and I'd
>>> like to see if we can reuse that file/concept/code to handle
>>> artifacts that don't have accompanying POMs on the remote repo.
>>> It's a similar concept, so the two should dovetail relatively
>>> well, and require little code to accomplish the fix.
>>
>> This makes sense to me. So continue to expand on the update check
>> manager to handle this case?
>>
>> The other alternative - which at one point we were doing - is to
>> write out the stub POM into the local repository and retain that.
>> It would simplify the code, but muddies the local repo content.
>>
>> I believe these have the same net effect, in that the artifact is
>> never resolved a second time. Is that correct?
>>
>>
>>>
>>>
>>> The way I see it, the biggest hurdle for this issue is creating a
>>> [set of] good tests to circumscribe the issue and make sure it
>>> doesn't regress later.
>>
>> I don't think there's too many variations - the problem is only
>> with missing POM files, right?
>>
>> Cheers,
>> Brett
>>
>>
>>>
>>>
>>> My $0.02.
>>>
>>> -john
>>>
>>> Brett Porter wrote:
>>>> Hi all,
>>>>
>>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha
>>>> release, I was looking at releasing an alpha of maven-artifact.
>>>> Brian was able to locate the issue he was referring to a couple
>>>> of weeks back about re-resolving (now MARTIFACT-25), so I've
>>>> postponed.
>>>>
>>>> Once that's fixed, I think there should be no reason not to
>>>> proceed with a release based on the thread we had back then.
>>>>
>>>> Are there any other issues that anyone sees as blocking moving
>>>> forward with a release?
>>>>
>>>> I've done all the testing I was planning to already. Oleg, did
>>>> you want to take this release, or shall I go ahead after that
>>>> issue is sorted?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> --
>> Brett Porter
>> brett@...
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [DISCUSS] Maven Team Conventions

2008-07-05T07:59:04Z

Thanks Benjamin, I agree with this.

On 05/07/2008, at 7:12 PM, Benjamin Bentmann wrote:

> Brett Porter wrote:
>
>> I disagree on JIRA issues - for making release notes and keeping
>> track I think it's best to have an issue whenever possible.
>
> Having detailed release notes is surely a good point since it's the
> easiest way for users to rate a new release in terms of benefits/
> risks when updating. But I guess something like "Improved javadoc"
> is not that interesting that it should popup in the release notes,
> i.e. Vincent's general distinction between "Minor changes" and
> "Larger changes" makes sense.
>
> However, I feel the statement
>
> jira.apt
> * <<Minor changes>>, like bug fixes
>
> is misleading. Of course there a "bug fixes" like correcting typos
> that can go in without jiras but in general I call a bug fix a major
> change that is going to impact users ("Jesus, they got that working,
> great!") ;-)
>
> Hence I propose the following update:
>
> * <<Minor changes>>, like code reformatting, documentation fixes,
> etc. that aren't going to impact other users can be committed
> without much issue.
>
> * <<Major changes>>, like bug fixes, API changes, significant
> refactoring, and pretty much any change of more than 100 lines,
> should have a JIRA ticket associated with it, or at least an email
> discussion.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Re: [DISCUSS] Maven Team Conventions

2008-07-05T06:30:40Z

Hi,

2008/7/5, Benjamin Bentmann <benjamin.bentmann@...>:

> Vincent Siveton wrote:
>
>
> >
> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions
> >
>
> code.apt
> * <<Documentation>>: Document public interfaces well, i.e. all non-trivial
> public and protected functions should include Javadoc that indicates what it
> does.
>
> I would like to point out there are almost no methods that are really
> non-trivial. In particular, getters and setters are not trivial.
>
> Take for instance getComponents() from the Plexus' ComponentSetDescriptor.
> This method returns a null collection if no components have been added to
> the list yet. The javadoc doesn't tell this "triviality" that can easily
> cause NPEs in client code (MPLUGIN-114, MNG-2087). BTW, new
> ComponentSetDescriptor().toString() also dies with a NPE.
>
> Concerning collections, other "trivial" aspects are whether to return
> writable/unmodifiable live views or snapshots. For input parameters, will a
> setter like setComponents() make a copy of the input collection or will
> later changes to the supplied collection by the caller affect the
> ComponentSetDescriptor?
>

I discourage the use of generated javadoc for getter/setter (not
really useful). If some getter make some internal things, the javadoc
is required.

> Being open-source appears to support the habbit of omitting documentation
> about member invariants and method pre-/postconditions. This in turn leaves
> clients with the only choice of evaluating the current implementation to
> derive the behavior. Then, nobody can tell what aspect of the behavior is
> considered part of the API and what is just implementation-specific/buggy.

Pre/post conditions are importants things IMHO, like could be null,
could return null etc.

> Just wondering what is more expensive or time consuming: Adding proper
> documentation right from the start or fixing potential API misuses
> afterwards?
>

Totally agree with you (concept of done in the agile way ;) )

The main question is:
Does the team want to refute any commits without proper javadoc?

Cheers,

Vincent

>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r674134 - in /maven/plugins/trunk/maven-site-plugin/src/main/resources: site-plugin_ca.properties site-plugin_sv.properties site-plugin_tr.properties

2008-07-05T06:22:24Z

Vincent Siveton wrote:

> So, I am in favour to use unicode to all resources bundles. What others think?

To repeat my argument from MSITE-287: I believe using ASCII only with
Unicode escapes is simply the most robust choice for an international
dev community. For instance, somebody who accidentially edits a Latin-1
resource bundle using UTF-8 will corrupt the contents. An ASCII-only
resource bundle in contrast is safe(r) because the characters will
successfully rountrip regardless of the encoding (neglecting exots like
EBCDIC).

Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [DISCUSS] Maven Team Conventions

2008-07-05T06:21:17Z

Hi,

2008/7/5, Brett Porter <brett@...>:
> Just a couple of comments...
>
> code.apt:
> ~~ * Using SVN properties like \$Id: \$ => Is it a wanted goal for all
> files like java or apt?
> I think this is helpful, though maybe optional. I don't really think it's

We can start to include it in all new files.

> good for the @version tag in Javadoc though.

Personally, I am in favour to use @version $Id:$ in javacode. The
important tag is @since.

> * <<Indentation>>: Always use 2 space indents and <<never>> use tabs!
> The two space rule is only for text files, right? We use 4 for Java in all
> indents, but the document doesn't indicate that.

Fixed

> * <<Readingness>>: Specify code grouping members, if needed. For instance
> in a Mojo class, you could have:
> I've found these are used inconsistently and get out of date. Like all
> comments, someone should add them if they think they'll help, but as a
> general rule I'd omit this.
>

Do we want to improves the readability of the code by sorting members?
If so, any recommended layout?

> jira.apt:
>
> I disagree on JIRA issues - for making release notes and keeping track I
> think it's best to have an issue whenever possible.
>

Other comments?

Cheers,

Vincent

> BTW, I posted some conventions to this list in the past, maybe we could
> incorporate them:
> http://markmail.org/message/wfv2lw66i2gggnaq
>
> Thanks,
> Brett
>
>
>
> On 04/07/2008, at 7:00 AM, Vincent Siveton wrote:
>
>
> >
> > Hi folks,
> >
> > Following recent discussions on dev@ about POM style [1] and Jira
> > versioning [2], I created several documents about our code style and
> > conventions, jira and svn conventions.
> >
> >
> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions
> >
> > It is for discussions and all comments are welcome :)
> >
> > Cheers,
> >
> > Vincent
> >
> > [1]
> http://www.nabble.com/-Proposal--Pom-Code-Style-(WAS-svn-commit%3A-r670264----maven-plugins-trunk-maven-site-plugin-pom.xml)-td18083228.html
> > [2]
> http://www.nabble.com/Re%3A--jira--Updated%3A-(MNG-3468)-FileSet-needs-a-toString()-method-to-properly-print-in-debug-mode-td18185825.html
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r674134 - in /maven/plugins/trunk/maven-site-plugin/src/main/resources: site-plugin_ca.properties site-plugin_sv.properties site-plugin_tr.properties

2008-07-05T06:01:21Z

Hi Dennis,

2008/7/5, Dennis Lundberg <dennisl@...>:
> I never really closed out the discussion we had earlier, regarding how to
> encode properties files. Now we have an example of a change of encoding of
> properties, so I want to take the opportunity to finish that discussion.
> Hopefully we can reach consensus this time :-) When we do I'll put into our
> code conventions docs.

+1 to create a Properties convention part.
Also, specify how to format key/value, ie having a consensus between
[1] or [2] layout.

>
> What is the benefit of the change you made here Vincent?

Mainly for consistency reasons with other resources bundles.
Also, it is a no cost issue since it is done by development tools.

>
> I proof read the Swedish translation (one of the files changed here) that
> was submitted earlier, before I committed it. When I look at the file now,
> it is totally unreadable for a human. That's because the accented character,
> found in ISO-8859-1 but not in ASCII, are now represented by unicode. How
> can I proof read such a document if it was submitted in unicode? Therefor I
> see more pain than gain from this type of change.
>

I understand your requirement about readability but modern IDEs
provide a way to convert native to ascii transparently.
In Eclipse world, you could use PropertiesEditor Plugin [3] (Take care
to change the default encoding to UTF-8, ie select Window >
Preferences and open up the configuration for PropertiesEditor)
In IDEA, you could select "transparent native-to-ascii conversion"
parameter in File > Settings and open up the General item.
Finally, some independent tools could help you [4] and [5].

So, I am in favour to use unicode to all resources bundles. What others think?

Cheers,

Vincent

[1] https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity.properties
[2] https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report_fr.properties

[3] http://propedit.sourceforge.jp/
[4] http://propedit.sourceforge.jp/propertieseditor.jnlp
[5] http://www.zaval.org/products/jrc-editor/index.html

[SNIP]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r674134 - in /maven/plugins/trunk/maven-site-plugin/src/main/resources: site-plugin_ca.properties site-plugin_sv.properties site-plugin_tr.properties

2008-07-05T04:28:56Z

I never really closed out the discussion we had earlier, regarding how
to encode properties files. Now we have an example of a change of
encoding of properties, so I want to take the opportunity to finish that
discussion. Hopefully we can reach consensus this time :-) When we do
I'll put into our code conventions docs.

What is the benefit of the change you made here Vincent?

I proof read the Swedish translation (one of the files changed here)
that was submitted earlier, before I committed it. When I look at the
file now, it is totally unreadable for a human. That's because the
accented character, found in ISO-8859-1 but not in ASCII, are now
represented by unicode. How can I proof read such a document if it was
submitted in unicode? Therefor I see more pain than gain from this type
of change.

vsiveton@... wrote:

> Author: vsiveton
> Date: Fri Jul 4 15:53:58 2008
> New Revision: 674134
>
> URL: http://svn.apache.org/viewvc?rev=674134&view=rev
> Log:
> o used unicode provided by Properties Editor Eclipse Plugin
>
> Modified:
> maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_ca.properties
> maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_sv.properties
> maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_tr.properties
>
> Modified: maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_ca.properties
> URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_ca.properties?rev=674134&r1=674133&r2=674134&view=diff
> ==============================================================================
> --- maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_ca.properties (original)
> +++ maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_ca.properties Fri Jul 4 15:53:58 2008
> @@ -15,12 +15,12 @@
> # specific language governing permissions and limitations
> # under the License.
>
> -report.category.column.description = Descripció
> +report.category.column.description = Descripci\u00f3
> report.category.column.document = Document
> report.category.sectionTitle = Resum
> -report.information.description1 = Aquest document presenta un resum dels diferents documents i enllaços que són part de la informació general del projecte. Tot aquest contingut és generat automàticament per
> +report.information.description1 = Aquest document presenta un resum dels diferents documents i enlla\u00e7os que s\u00f3n part de la informaci\u00f3 general del projecte. Tot aquest contingut \u00e9s generat autom\u00e0ticament per
> report.information.description2 = en nom d'aquest projecte.
> -report.information.title = Informació general del projecte
> -report.project.description1 = Aquest document presenta un resum de diversos informes que són generats automàticament per
> -report.project.description2 = Cada informe està descrit breument més endavant.
> +report.information.title = Informaci\u00f3 general del projecte
> +report.project.description1 = Aquest document presenta un resum de diversos informes que s\u00f3n generats autom\u00e0ticament per
> +report.project.description2 = Cada informe est\u00e0 descrit breument m\u00e9s endavant.
> report.project.title = Informes Generats per Maven
>
> Modified: maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_sv.properties
> URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_sv.properties?rev=674134&r1=674133&r2=674134&view=diff
> ==============================================================================
> --- maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_sv.properties (original)
> +++ maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_sv.properties Fri Jul 4 15:53:58 2008
> @@ -17,10 +17,10 @@
>
> report.category.column.description = Beskrivning
> report.category.column.document = Dokument
> -report.category.sectionTitle = Översikt
> -report.information.description1 = Detta dokument ger en översikt över de dokument och länkar som utgör projektets generella information. Allt innehåll genereras automatiskt av
> -report.information.description2 = åt projektet.
> +report.category.sectionTitle = \u00d6versikt
> +report.information.description1 = Detta dokument ger en \u00f6versikt \u00f6ver de dokument och l\u00e4nkar som utg\u00f6r projektets generella information. Allt inneh\u00e5ll genereras automatiskt av
> +report.information.description2 = \u00e5t projektet.
> report.information.title = Projektinformation
> -report.project.description1 = Detta dokument ger en översikt över de rapporter som genereras av
> +report.project.description1 = Detta dokument ger en \u00f6versikt \u00f6ver de rapporter som genereras av
> report.project.description2 = Varje rapport beskrivs kort nedan.
> report.project.title = Projektrapporter
>
> Modified: maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_tr.properties
> URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_tr.properties?rev=674134&r1=674133&r2=674134&view=diff
> ==============================================================================
> --- maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_tr.properties (original)
> +++ maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_tr.properties Fri Jul 4 15:53:58 2008
> @@ -15,12 +15,12 @@
> # specific language governing permissions and limitations
> # under the License.
>
> -report.category.column.description = Taným
> -report.category.column.document = Doküman
> -report.category.sectionTitle = Genel Bakýþ
> +report.category.column.description = Tan\u00fdm
> +report.category.column.document = Dok\u00fcman
> +report.category.sectionTitle = Genel Bak\u00fd\u00fe
> report.information.description1 = This document provides an overview of the various documents and links that are part of this project's general information. All of this content is automatically generated by
> report.information.description2 = on behalf of the project.
> report.information.title = Proje Bilgileri
> report.project.description1 = This document provides an overview of the various reports that are automatically generated by
> report.project.description2 = Each report is briefly described below.
> -report.project.title = Geliþtirilmiþ Raporlar
> +report.project.title = Geli\u00fetirilmi\u00fe Raporlar
>
>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [DISCUSS] An inherited "Maven Projects" menu for on all our sites

2008-07-05T04:10:27Z

Thanks to everybody who came up with idea for improvement!

I'm going to start implementing this now. To start out in an agile way,
I will put this into the Maven site. That way we can easily change
things and just push out a new site.

When we have settled in on what we want I'll start moving it over to a
parent.

Brett Porter wrote:

>
> On 30/06/2008, at 5:00 AM, Dennis Lundberg wrote:
>
>> Vincent Siveton wrote:
>>> Excellent work Dennis!
>>> About the "Maven projects" list, I think maven 2 should be in first to
>>> improve the usability.
>>
>> I doubt it will make things more usable. I find that ordering stuff
>> alphabetically is more accessible that having them ordered by
>> "importance". Simply because what is important to you might not be
>> important to the next guy.
>>
>> Also accessing the main Maven site, which is where you'd go when you
>> click on "Maven 2", will be easily accessible from the breadcrumbs at
>> all times.
>
> Agreed. However, personally I'd drop Maven 1.x from the list and rename
> Maven 2 to Maven.
>
>>
>>
>>> In this case, wdyt to put a list with expanded sub projects (not sure
>>> about the rendering)
>>
>> Not sure I follow you here. Do you mean we should turn each sub
>> project's menu item into an expandable menu? If so, what would the
>> menu items of that menu be?
>
> Maybe for shared components and plugins this would make some sense?
>
> Last bit of feedback from me: I think the jump out arrows are erroneous.
>
> Thanks Dennis!
>
> - Brett
>
>>
>>
>>> Cheers,
>>> Vincent
>>> 2008/6/29, Dennis Lundberg <dennisl@...>:
>>>> OK, listening to the suggestions and coming up with a second attempt:
>>>>
>>>> http://people.apache.org/~dennisl/inherited-menu-2.png
>>>>
>>>> Feedback still wanted: negative or positive.
>>>>
>>>>
>>>> Jesse McConnell wrote:
>>>>
>>>>> I agree with vincent and this is a great improvement
>>>>>
>>>>> nice!
>>>>>
>>>>> jesse
>>>>>
>>>>> On Wed, Jun 25, 2008 at 10:22 AM, Dennis Lundberg <dennisl@...>
>>>> wrote:
>>>>>> Benjamin Bentmann wrote:
>>>>>>
>>>>>>> Dennis Lundberg schrieb:
>>>>>>>
>>>>>>>
>>>>>>>> I want to separate "Maven Projects", as they are called in the menu
>>>> of
>>>>>>>> the main site, from breadcrumbs that tells you where on the site
>>>>>>>> you
>>>>>>>> currently are.
>>>>>>>>
>>>>>>> +1, moving the "Maven Projects" out of the breadcrumbs scales better
>>>> with
>>>>>>> increasing project number.
>>>>>>>
>>>>>>>
>>>>>>>> My current work has breadcrumbs to the right of the publish date
>>>>>>>> and
>>>>>>>> version.
>>>>>>>>
>>>>>>> Agree with Vincent, I would prefer to have the publish date and
>>>> version on
>>>>>>> the right such that the breadcrumbs are the first item that meets
>>>>>>> the
>>>> eye.
>>>>>>> BTW, the Maven main site shows a version (1.0), shouldn't we remove
>>>> that?
>>>>>>> It seems irrelevant to the reader and might also be confusing (if
>>>> you're
>>>>>>> looking for Maven 2.x and not 1.0).
>>>>>>>
>>>>>> See http://svn.apache.org/viewvc?rev=670736&view=rev
>>>>>>
>>>>>>
>>>>>>>> [1]
>>>> http://people.apache.org/~dennisl/inherited-menu.png
>>>>>>> Thanks Dennis, really looking forward to the next Site Plugin.
>>>>>>>
>>>>>> It shouldn't be long now. If all goes well this weekend.
>>>>>>
>>>>>>
>>>>>>> Benjamin
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@...
>>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Dennis Lundberg
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@...
>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Dennis Lundberg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [DISCUSS] Maven Team Conventions

2008-07-05T03:16:40Z

Vincent Siveton wrote:

> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions

code.apt
* <<Documentation>>: Document public interfaces well, i.e. all
non-trivial public and protected functions should include Javadoc that
indicates what it does.

I would like to point out there are almost no methods that are really
non-trivial. In particular, getters and setters are not trivial.

Take for instance getComponents() from the Plexus'
ComponentSetDescriptor. This method returns a null collection if no
components have been added to the list yet. The javadoc doesn't tell
this "triviality" that can easily cause NPEs in client code
(MPLUGIN-114, MNG-2087). BTW, new ComponentSetDescriptor().toString()
also dies with a NPE.

Concerning collections, other "trivial" aspects are whether to return
writable/unmodifiable live views or snapshots. For input parameters,
will a setter like setComponents() make a copy of the input collection
or will later changes to the supplied collection by the caller affect
the ComponentSetDescriptor?

Being open-source appears to support the habbit of omitting
documentation about member invariants and method pre-/postconditions.
This in turn leaves clients with the only choice of evaluating the
current implementation to derive the behavior. Then, nobody can tell
what aspect of the behavior is considered part of the API and what is
just implementation-specific/buggy.

Just wondering what is more expensive or time consuming: Adding proper
documentation right from the start or fixing potential API misuses
afterwards?

Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [DISCUSS] Maven Team Conventions

2008-07-05T02:12:18Z

Brett Porter wrote:

> I disagree on JIRA issues - for making release notes and keeping track I
> think it's best to have an issue whenever possible.

Having detailed release notes is surely a good point since it's the
easiest way for users to rate a new release in terms of benefits/risks
when updating. But I guess something like "Improved javadoc" is not that
interesting that it should popup in the release notes, i.e. Vincent's
general distinction between "Minor changes" and "Larger changes" makes
sense.

However, I feel the statement

jira.apt
* <<Minor changes>>, like bug fixes

is misleading. Of course there a "bug fixes" like correcting typos that
can go in without jiras but in general I call a bug fix a major change
that is going to impact users ("Jesus, they got that working, great!") ;-)

Hence I propose the following update:

* <<Minor changes>>, like code reformatting, documentation fixes, etc.
that aren't going to impact other users can be committed without much issue.

* <<Major changes>>, like bug fixes, API changes, significant
refactoring, and pretty much any change of more than 100 lines, should
have a JIRA ticket associated with it, or at least an email discussion.

Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Maven 2.x Eclipse Plugin - MECLIPSE-388

2008-07-04T23:16:05Z

I know working with J2ME this is handy if the JRE_CONTAINER can come
last.

What I'd like to see (and I filed a JIRA for it) is /src/*/resources
added as library references, rather than source folders.

Christian.

On 4-Jul-08, at 21:25 , Kamil wrote:

> Additional I guess Only
> JRE_CONTAINER can be last to give user ability to override default
> system
> libraries with provided in pom.xml (or it should be as same in core
> maven -
> jre libraries are first or last)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [DISCUSS] Maven Team Conventions

2008-07-04T22:31:51Z

Just a couple of comments...

code.apt:
~~ * Using SVN properties like \$Id: \$ => Is it a wanted goal for all
files like java or apt?
I think this is helpful, though maybe optional. I don't really think
it's good for the @version tag in Javadoc though.

* <<Indentation>>: Always use 2 space indents and <<never>> use tabs!
The two space rule is only for text files, right? We use 4 for Java in
all indents, but the document doesn't indicate that.

* <<Readingness>>: Specify code grouping members, if needed. For
instance in a Mojo class, you could have:
I've found these are used inconsistently and get out of date. Like all
comments, someone should add them if they think they'll help, but as a
general rule I'd omit this.

jira.apt:

I disagree on JIRA issues - for making release notes and keeping track
I think it's best to have an issue whenever possible.

BTW, I posted some conventions to this list in the past, maybe we
could incorporate them: http://markmail.org/message/wfv2lw66i2gggnaq

Thanks,
Brett

On 04/07/2008, at 7:00 AM, Vincent Siveton wrote:

> Hi folks,
>
> Following recent discussions on dev@ about POM style [1] and Jira
> versioning [2], I created several documents about our code style and
> conventions, jira and svn conventions.
>
> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions
>
> It is for discussions and all comments are welcome :)
>
> Cheers,
>
> Vincent
>
> [1] http://www.nabble.com/-Proposal--Pom-Code-Style-(WAS-svn-commit%3A-r670264----maven-plugins-trunk-maven-site-plugin-pom.xml)-td18083228.html
> [2] http://www.nabble.com/Re%3A--jira--Updated%3A-(MNG-3468)-FileSet-needs-a-toString()-method-to-properly-print-in-debug-mode-td18185825.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Maven 2.x Eclipse Plugin - MECLIPSE-388

2008-07-04T18:25:40Z

Hi

Maven 2.0.9 has corrected classpath order, direct dependencies are first
(and suborder is among declared entries). I think that thanks this very
hopefilly improvement (bugfix imho ;)) maven eclipse plugin doesn't have to
sort classpath. Generated .classpath should sorted entries amond order in
pom.xml (and eg no push to first javax/java packages - if somebody wants it
push first it could declared them first in pom.xml). Additional I guess Only
JRE_CONTAINER can be last to give user ability to override default system
libraries with provided in pom.xml (or it should be as same in core maven -
jre libraries are first or last)

--
Kamil

Re: Vetting issues for 2.1-alpha-XX

2008-07-04T09:17:59Z

As part of getting adequate coverage for vetting, I have just asked
Nigel and Justin who watch over the Hudson instance here at Apache to
setup the Maven jobs we require for validation. They are running on
Solaris which will be a good compliment to what we have running at
Contegix.

Hopefully this will be setup today and then we'll have Linux and
Solaris dealth with in a reliable, automated way. I've asked Contegix
to order a Mac Mini they will modify and put in our rack, and we will
have a big machine that will run ESX coming soon as well so we'll be
able to deal with different flavors of Windows and *nix.

On 3-Jul-08, at 10:43 PM, Jason van Zyl wrote:

> I have chopped the issue list down to what I know I'm going to look
> at here:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10500&fixfor=13143
>
> If you want to add things you know you want to look at, go for it.
>
> But I would like to use a standard build for testing. I am going to
> use the version of Maven built by Hudson from the 2.1 build that's
> been cycling off from here:
>
> http://ci.sonatype.org/view/Maven%202.1x/job/Maven-2.1.x/
>
> If we sync up on a version which we all use then we have a good
> chance of getting consistent results. I'm using the build from here
> to review the issues currently in the queue:
>
> http://ci.sonatype.org/view/Maven%202.1x/job/Maven-2.1.x/ws/maven-2.1.x/maven-distribution/target/
>
> When issues are closed, another build can be done and we can use
> that one to carry on. I think this is the only sane way to work
> through the issues. The Hudson instance has been up the longest, it
> works more reasonably then anything else we've used, and John has
> been working on creating some release automation so the releases can
> be built on the same machine as well. For reliability and
> consistency I think this is a reasonable approach.
>
> A PowerEdge 2900 will land at Contegix shortly that has been
> provisioned to run ESX so that we can deal with Windows, Linux, BSD,
> and Solaris in an automated way. Contegix also said they could wire
> up a MAC mini if we wanted to automate OS X builds as well. The box
> is on Contegix's system, but any PMC member can get access to the
> machine and access to the support list if you need to contact
> support in the middle of the night.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will
> come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Three people can keep a secret provided two of them are dead.

-- Unknown

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

2008-07-04T08:51:40Z

John - are you looking into this? Need it resolved for MNG-3185

Thanks,
Oleg

Brett Porter wrote:

>
> On 04/07/2008, at 3:40 AM, John Casey wrote:
>
>> Not to distract from the higher-level discussion, but I'd like to get
>> into the nuts and bolts of MARTIFACT-25 a bit...in case someone beats
>> me to it.
>>
>> We introduced a properties file that tracks resolution attempts for
>> artifacts that weren't found on the remote repository, and I'd like
>> to see if we can reuse that file/concept/code to handle artifacts
>> that don't have accompanying POMs on the remote repo. It's a similar
>> concept, so the two should dovetail relatively well, and require
>> little code to accomplish the fix.
>
> This makes sense to me. So continue to expand on the update check
> manager to handle this case?
>
> The other alternative - which at one point we were doing - is to write
> out the stub POM into the local repository and retain that. It would
> simplify the code, but muddies the local repo content.
>
> I believe these have the same net effect, in that the artifact is
> never resolved a second time. Is that correct?
>
>
>>
>>
>> The way I see it, the biggest hurdle for this issue is creating a
>> [set of] good tests to circumscribe the issue and make sure it
>> doesn't regress later.
>
> I don't think there's too many variations - the problem is only with
> missing POM files, right?
>
> Cheers,
> Brett
>
>
>>
>>
>> My $0.02.
>>
>> -john
>>
>> Brett Porter wrote:
>>> Hi all,
>>>
>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha
>>> release, I was looking at releasing an alpha of maven-artifact.
>>> Brian was able to locate the issue he was referring to a couple of
>>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>>
>>> Once that's fixed, I think there should be no reason not to proceed
>>> with a release based on the thread we had back then.
>>>
>>> Are there any other issues that anyone sees as blocking moving
>>> forward with a release?
>>>
>>> I've done all the testing I was planning to already. Oleg, did you
>>> want to take this release, or shall I go ahead after that issue is
>>> sorted?
>>>
>>> Cheers,
>>> Brett
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

2008-07-04T08:44:15Z

Are you dropping new files into the local repository or integrating
this as part of the metadata? Do these files only work locally?

Also in the case of 2.1 we should also consider just not allowing the
state where there is no POM. Consider the artifact not complete
without a POM.

On 4-Jul-08, at 11:29 AM, Brett Porter wrote:

>
> On 04/07/2008, at 3:40 AM, John Casey wrote:
>
>> Not to distract from the higher-level discussion, but I'd like to
>> get into the nuts and bolts of MARTIFACT-25 a bit...in case someone
>> beats me to it.
>>
>> We introduced a properties file that tracks resolution attempts for
>> artifacts that weren't found on the remote repository, and I'd like
>> to see if we can reuse that file/concept/code to handle artifacts
>> that don't have accompanying POMs on the remote repo. It's a
>> similar concept, so the two should dovetail relatively well, and
>> require little code to accomplish the fix.
>
> This makes sense to me. So continue to expand on the update check
> manager to handle this case?
>
> The other alternative - which at one point we were doing - is to
> write out the stub POM into the local repository and retain that. It
> would simplify the code, but muddies the local repo content.
>
> I believe these have the same net effect, in that the artifact is
> never resolved a second time. Is that correct?
>
>
>>
>>
>> The way I see it, the biggest hurdle for this issue is creating a
>> [set of] good tests to circumscribe the issue and make sure it
>> doesn't regress later.
>
> I don't think there's too many variations - the problem is only with
> missing POM files, right?
>
> Cheers,
> Brett
>
>
>>
>>
>> My $0.02.
>>
>> -john
>>
>> Brett Porter wrote:
>>> Hi all,
>>>
>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha
>>> release, I was looking at releasing an alpha of maven-artifact.
>>> Brian was able to locate the issue he was referring to a couple of
>>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>>
>>> Once that's fixed, I think there should be no reason not to
>>> proceed with a release based on the thread we had back then.
>>>
>>> Are there any other issues that anyone sees as blocking moving
>>> forward with a release?
>>>
>>> I've done all the testing I was planning to already. Oleg, did you
>>> want to take this release, or shall I go ahead after that issue is
>>> sorted?
>>>
>>> Cheers,
>>> Brett
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

2008-07-04T08:29:16Z

On 04/07/2008, at 3:40 AM, John Casey wrote:

> Not to distract from the higher-level discussion, but I'd like to
> get into the nuts and bolts of MARTIFACT-25 a bit...in case someone
> beats me to it.
>
> We introduced a properties file that tracks resolution attempts for
> artifacts that weren't found on the remote repository, and I'd like
> to see if we can reuse that file/concept/code to handle artifacts
> that don't have accompanying POMs on the remote repo. It's a similar
> concept, so the two should dovetail relatively well, and require
> little code to accomplish the fix.

This makes sense to me. So continue to expand on the update check
manager to handle this case?

The other alternative - which at one point we were doing - is to write
out the stub POM into the local repository and retain that. It would
simplify the code, but muddies the local repo content.

I believe these have the same net effect, in that the artifact is
never resolved a second time. Is that correct?

>
>
> The way I see it, the biggest hurdle for this issue is creating a
> [set of] good tests to circumscribe the issue and make sure it
> doesn't regress later.

I don't think there's too many variations - the problem is only with
missing POM files, right?

Cheers,
Brett

>
>
> My $0.02.
>
> -john
>
> Brett Porter wrote:
>> Hi all,
>>
>> As I indicated a couple of weeks back, moving towards a 2.1 alpha
>> release, I was looking at releasing an alpha of maven-artifact.
>> Brian was able to locate the issue he was referring to a couple of
>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>
>> Once that's fixed, I think there should be no reason not to proceed
>> with a release based on the thread we had back then.
>>
>> Are there any other issues that anyone sees as blocking moving
>> forward with a release?
>>
>> I've done all the testing I was planning to already. Oleg, did you
>> want to take this release, or shall I go ahead after that issue is
>> sorted?
>>
>> Cheers,
>> Brett
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>